fix(remote): let the image recipe survive a new base AMI - #140

Unblocks spinloop remote bootstrap on an account whose image stack predates the current Ubuntu release.

Summary

• Name each Image Builder recipe after the base AMI it was built on, so a new Ubuntu release replaces the recipe instead of colliding with it.
• Bump RUNNER_VERSION to 3.5.0 for both runners, so the components and recipes replace cleanly and the AMIs pick up the outfit -> spinloop rename.
• Cover the recipe naming with a test, and correct the README troubleshooting entry, which blamed the operator for a base-image change they do not control.

Implementation details

The recipe reads the current Ubuntu 24.04 SSM alias, so Canonical publishing a new image changes parentImage between two deploys of otherwise unchanged code. Every recipe property is create-only, so that forces a replacement, and Image Builder rejects a create at a name and version that already exist — the replacement collides with the recipe it is replacing. Folding the AMI id into the name gives the replacement somewhere to land. The id is a deploy-time token, so it cannot be hashed at synth; putting it in the name is the only place it can be carried without a context lookup that would need the account in the stack's env.

Changes we do control still rely on a RUNNER_VERSION bump, and one was owed: the outfit -> spinloop rename moved the baked daemon directory to /var/lib/spinloop and the crash-nudge unit to spinloop-nudge, both of which lambda/runners/daemon-boot.ts pins by their new names. A 3.4.0 AMI logrotates a path nothing writes to and has no timer for the boot script to enable, so those AMIs need a rebake regardless.